FIG. 1 is a composition schematic diagram of the system architecture of the Evolved Packet System (EPS) in the related art, and as shown in FIG. 1, the EPS of the 3rd Generation Partnership Project (3GPP) comprises: an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a Mobility Management Entity (MME), a Serving Gateway (S-GW), a Packet Data Network Gateway (P-GW), a Home Subscriber Server (HSS), a 3GPP Authentication Authorization Accounting (AAA), a Policy and Charging Rules Function (PCRF) and other support nodes.
The MME is for related works of the control plane such as mobility management, non-access stratum signaling processing and user mobility management context management and so on; the S-GW is an access gateway device connected with the E-UTRAN, and is used to forward data between the E-UTRAN and P-GW and is responsible for caching the paging waiting data; and the P-GW is a border gateway between the EPS and Packet Data Network (PDN), and is responsible for functions such as accessing the PDN and forwarding data between the EPS and PDN and so on.
As shown in FIG. 1, the EPS supports interconnection with a non 3GPP network and implements the interconnection with the non 3GPP network through S2a/b/c interfaces. The non 3GPP network includes a trusted non 3GPP network and an untrusted non 3GPP network, wherein the IP access of the trusted non 3GPP network can be directly connected with the P-GW through the S2a; and the IP access of the untrusted non 3GPP network needs to be connected with the P-GW through the Evolved Packet Data Gateway (ePDG), and the interface between the ePDG and P-GW is the S2b. UE can also be connected with the P-GW through the S2c interface adopting the DSMIPv6 protocol.
If the EPS system supports that the PCRF of the Policy and Charging Control (PCC) makes the policy and charging rules, then the EPS system connects with the Internet Protocol (IP) service network of the operator through the receiving interface Rx and obtains the service information; furthermore, the EPS system connects with the gateway device in the network through Gx/Gxa/Gxc interfaces, and is responsible for initiating the IP bearer establishment, ensures the Quality of Service (QoS) of the service data, and performs charging control.
The Policy and Charging Enforcement Function (PCEF) is located in the P-GW, and the PCRF and the P-GW exchange information via the Gx interface. When the interface between the P-GW and the S-GW is based on the Proxy Mobile IP (PMIP), the S-GW has a Bearer Binding and Event Report Function (BBERF), and the S-GW and the PCRF exchange information via the Gxc interface. When a trusted non 3GPP network is accessed, a BBERF also resides in the trusted non 3GPP access gateway, and the trusted non 3GPP access gateway and the PCRF exchange information via the Gxa interface. When the User Equipment (UE) is roaming, the interface between the home PCRF and the visited PCRF is the S9 interface, meanwhile, the Application Function (AF) which provides a service for the UE is located in the service network, and sends the service information used to generate the PCC policy to the PCRF through the Rx interface.
The EPS has two kinds of roaming architecture, and FIG. 2 is a schematic diagram of one kind of roaming architecture in the EPS system in the related art. FIG. 2 shows home routed, that is to say, the P-GW is located in the home network and the IP service is provided by the operators of the home network (that is, the AF is in the home network);
FIG. 3 is a schematic diagram of another kind of roaming architecture in the EPS system in the related art, and FIG. 3 shows the local breakout, that is to say, the P-GW is located in the visited network, and the IP service can be provided by the operators of the home network or by the operators of the visited network can provide a IP service. For different roaming scenarios, the processes of the PCC are different, and the functions enforced by the PCC network elements are also different.
The EPS system supports multiple PDNs access, and the UE can access multiple PDNs by one or more P-GWs at the same time, that is, one UE can have multiple PDN connections at the same time. Generally, one connection from the UE to the PDN network is called as one IP-CAN session, that is to say, the EPS supports that the UE is able to have a plurality of IP-CAN sessions simultaneously.
In the related art, the protocol adopted in the PCC architecture is a Diameter application protocol developed on the basis of the Diameter Base Protocol, such as the application protocol applied in the Gx interface, the application protocol applied in the Rx interface, the application protocol applied in the Gxx interface (including the Gxa and Gxc interfaces) and the application protocol applied in the roaming interface S9 and so on. These application protocols define the messages, commands and Attribute Value Pairs (AVP), etc. used for the PCC. The Diameter sessions which are established by these protocols can become a Gx session, a Gxx session, an Rx session and an S9 session respectively. Each function entity of the PCC performs policy and charging control on the PDN connection established for the UE accessing the network through these sessions. The PCC architecture has defined the Diameter application protocols which are used in a non roaming scenario at present, such as the application protocol applied in the Gx interface, the application protocol applied in the Rx interface and the application protocol applied in the Gxx interface (including the Gxa and Gxc interfaces) and so on. These protocols define the messages, commands and AVP, etc. used for the PCC.
In the related art, one IP-CAN session relates to multiple network elements. In order to obtain the policy control rules for controlling this IP-CAN session or provide the information for establishing the policy control rules, each network element will establish a Diameter session with the PCRF respectively. Thus, one IP-CAN session will be associated with multiple Diameter sessions, and these Diameter sessions are all established, maintained and deleted by adopting the Diameter protocol.
At present, the scheme of implementing an S9 roaming interface is that: for each UE, the vPCRF terminates the Gx session and Gxx session existing in the visited network of all the IP-CAN sessions established by the UE, and uses one S9 session to transmit the information in the Gx session and Gxx session of all the IP-CAN sessions without terminating the Rx session in the visited network of all the IP-CAN sessions, and just forwards the messages of the Rx session to the home PCRF (hPCRF), and takes the visited PCRF (vPCRF) as one proxy. One S9 session probably has multiple subsessions, which are called as the S9 subsessions. Each subsession is used to transmit the information in the Gx session and Gxx session of one IP-CAN session.
When the BBERF relocation occurs, such as when the UE performs an inter-system handover or an inter-system pre-registration and so on, the PCRF needs to control two or more BBERFs located in different systems at the same time, wherein one is called as the Primary BBERF, and the others are called as the Non-Primary BBERF. The PCRF saves the QoS rules and states of BBERFs for each BBERF respectively at the same time, and the operations on these BBERFs are also different. For example, when the PCRF needs to update the QoS rules, the hPCRF will send the updated QoS rules to these BBERF at the same time, if the Primary BBERF can not successfully install the QoS rules, the Primary BBERF will report the situation to the hPCRF, and the hPCRF will delete the same QoS rules in the Non-Primary BBERFs, and also delete the corresponding PCC rules in the PCEF. If the Non-Primary BBERF can not successfully install the QoS rules, the Primary BBERF will report the situation to the hPCRF, and then the PCRF just updates the QoS rules and states which are saved for the Non-Primary BBERF in the PCRF without carrying out the other operations. Of course, there are other different operations performed by the hPCRF with respect to the Primary BBERF and Non-Primary BBERF, which will not be repeated here.
FIG. 4 is a flow chart of establishing the IP-CAN session of the UE accessing the EPS through the E-UTRAN or trusted non 3GPP access gateway in the roaming scenario of the home routed in the related art, and it is assumed that the PMIPv6 protocol is adopted between the S-GW and P-GW when accessing the E-UTRAN and the PMIPv6 protocol is adopted between the access gateway and P-GW when accessing the non 3GPP access gateway. As shown in FIG. 4, the following steps are comprised.
Step 400: the BBERF receives an establishment IP-CAN session request message, and obtains a user identity for example a Network Access Identity (NAI), a PDN identity and access information for making a policy, wherein the access information includes the network identity of the network in which the BBERF is located, the current position information of UE, the address of the BBERF and the IP-CAN type or the RAT type and so on.
The BBERF can be located in the S-GW or the trusted non 3GPP access gateway.
Step 401: the BBERF sends a gateway control session establishment indication message to the vPCRF, and the gateway control session establishment indication message includes a user identity, PDN identity and access information for making a policy. The Gxx session established by the gateway control session establishment indication message is called as Gxx session1.
Step 402: the vPCRF sends an S9 session establishment indication message to the hPCRF, and includes the user identity, the PDN identity and the access information for making the policy which are included in the gateway control session establishment indication message in the step 401 into the Subsession1, and further includes Subsession1 into the S9 session establishment indication message to send to the hPCRF. The vPCRF records the association relationship between the Gxx session1 and Subsession1.
In this step, the vPCRF determines that the user is a roaming user according to the user identity, thus determines that the UE adopts a home routed and the hPCRF supports the functions of the Gxx interface according to the PDN identity and roaming agreement. Then, the vPCRF determines an S9 session has not been established for the user by itself, terminates the Gxx session, initiates to establish a new Diameter session namely an S9 session with the hPCRF, and makes a request for establishing a subsession, which is called as Subsession1, in the S9 session.
Step 403: the hPCRF saves the reported access information, and interacts with the user Subscription Profile Repository (SPR) according to the user identity and PDN identity to obtain the subscription information of the UE, and makes the default PCC rules, QoS rules, and event triggers according to the network policy and reported access information, etc. The hPCRF sends an S9 session establishment acknowledgement message to the vPCRF, and the QoS rules and event triggers are included in the Subsession1 and included in the S9 session establishment acknowledgement message.
Step 404: the vPCRF sends a gateway control session establishment acknowledgement message to the BBERF, and the gateway control session establishment acknowledgement message includes the QoS rules and event triggers obtained from the S9 session establishment acknowledgement message so that the BBERF installs the QoS rules and event triggers.
The vPCRF sends the QoS rules and event triggers included in the Subsession 1 to the BBERF by the Gxx session 1 according to the association relationship between the Subsession 1 and Gxx session 1.
The vPCRF can modify the QoS rules and event triggers sent by the hPCRF according to the policy of the visited network, and at the moment, the step 405 sends the modified QoS rules and event triggers so that the BBERF installs the modified QoS rules and event triggers.
Step 405: the gateway in which the BBERF is located sends an establishment IP-CAN session request message to the P-GW, and the establishment IP-CAN session request message includes information such as a NAI identity of the UE, PDN identity, and IP-CAN type or RAT type of the access network and so on. In the implementation, the establishment IP-CAN session request message is a proxy binding update message.
Herein, step 405 can be carried out with step 401 at the same time without waiting for the messages returned by step 404.
Step 406: as the example is the home routed, the P-GW is in a home network. The P-GW allocates an IP address for the UE, and the PCEF which resides in the P-GW sends an IP-CAN session establishment indication message to the hPCRF, and the IP-CAN session establishment indication message includes a user identity, IP address allocated for the UE, PDN identity and access information (the IP-CAN type or RAT type reported in step 405) for making a policy.
The Gx session established by the IP-CAN session establishment indication message is called as Gx session1.
Step 407: the hPCRF associates the Gx session1 with the S9 session established in step 402 according to the user identity, and associates the Gx session1 with the Subsession1 according to the user identity and PDN identity. The hPCRF sends the PCC rules and event triggers made previously to the PCEF by the IP-CAN session establishment acknowledgement message. Since there is only one BBERF at present, the BBERF can be considered as a Primary BBERF. Of course, the hPCRF can determine that the BBERF is a Primary BBERF according to the IP-CAN type or RAT type reported in step 406 is the same as the IP-CAN type or RAT type reported in step 402.
The PCEF installs the sent PCC rules and event triggers after receiving the acknowledgement message, and the hPCRF can also modify the made PCC rules according to the access information for making the policy provided by the PCEF, and thus, the hPCRF sends the modified PCC rules.
Step 408: the P-GW returns an establishment IP-CAN session reply to the gateway in which the BBERF is located. In the implementation, the establishment IP-CAN session reply is a proxy binding update acknowledgement message. The establishment IP-CAN session reply can be initiated without waiting for the acknowledgement message in the step 407.
Step 409: the gateway in which the BBERF is located returns the establishment IP-CAN session reply.
FIG. 5 is a flow chart of modifying the IP-CAN session of the UE accessing the EPS through the E-UTRAN or trusted non 3GPP access gateway in the roaming scenario of the home routed in the related art, and it is assumed that an IP-CAN session modification is caused by the occurrence of the BBERF relocation (e.g. the UE performing handover or inter-system pre-registration) after establishing the IP-CAN session of accessing the EPS as shown in the FIG. 4. And it is assumed that the PMIPv6 protocol is adopted between the S-GW and P-GW when accessing the E-UTRAN and the PMIPv6 protocol is adopted between the access gateway and P-GW when accessing the non 3GPP access gateway. As shown in FIG. 5, the following steps are comprised.
Step 500: the New BBERF receives an establishment IP-CAN session request message, and obtains a user identity, PDN identity and access information for making a policy, etc. And the access information includes the network identity of the New BBERF, the current position information of UE and the IP-CAN type or RAT type of the access network and so on.
Step 501: the New BBERF sends a gateway control session establishment indication message to the vPCRF, and the gateway control session establishment indication message includes a user identity, PDN identity and an access information for making a policy and so on, and the access information includes the network identity of the network in which the New BBERF is located, the current position information of UE, the address of the New BBERF and the IP-CAN type or RAT type of the new access network and so on. The Gxx session established by the gateway control session establishment indication message is represented as Gxx session 2.
Step 502: the vPCRF sends an S9 session modification indication message to the hPCRF to make a request for modifying the Subsession1, and includes the new access information (including the address of the New BBERF and the IP-CAN type or RAT type of the new access network) of the UE into the Subsession1 to send to the hPCRF.
The vPCRF determines that an S9 session has been established for the user according to the user identity, and determines that the UE performs the handover according to the user identity, PDN identity and access network information (e.g. the address of the New BBERF).
The vPCRF associates the Gxx session 2 with the Subsession 1 according to the user identity and PDN identity.
Step 503: the hPCRF sends an S9 session modification acknowledgement message to the vPCRF, and the S9 session modification acknowledgement message includes the Subsession1 which includes the QoS rules, event triggers and the address of the New BBERF, wherein the address of the New BBERF is used to identify that the information such as the QoS rules and event triggers and so on in the Subsession1 of the message is with respect to the New BBERF.
The hPCRF determines the UE performs handover according to the address of the New BBERF is different from the address of the Old BBERF, and re-makes the QoS rules according to the new access information of the UE. At the moment, the hPCRF will determine which BBERF is a Primary BBERF and which BBERF is a Non-primary BBERF. If the IP-CAN type or RAT type of the new access network reported by the New BBERF in step 502 is different from the IP-CAN type or RAT type of the access network reported by the PCEF in step 406 of FIG. 4, then the hPCRF determines that the New BBERF is a Non-Primary BBERF and the Old BBERF is still a Primary BBERF.
Step 504: the vPCRF sends a gateway control session establishment acknowledgement message to the New BBERF, and the gateway control session establishment acknowledgement message includes the new QoS rules. The New BBERF installs the new QoS rules after receiving the gateway control session establishment acknowledgement message.
The vPCRF sends the QoS rules and event triggers in the Subsession1 to the New BBERF through the Gxx session2 according to the address of the New BBERF.
The vPCRF can modify the QoS rules and event triggers according to the policy, and send the modified QoS rules and event triggers to the New BBERF.
From this moment, the hPCRF will carry out different operations for the Primary BBERF and Non-Primary BBERF. The flow of the UE performing inter-system pre-registration ends up to now, and the flow of the handover of the UE continues the following steps.
Step 505: the gateway in which the New BBERF is located sends an IP-CAN session signaling message to the P-GW, and the IP-CAN session signaling message includes the user identity and the PDN identity. In the implementation, the IP-CAN session signaling message is the proxy binding update message of PMIPv6, and the IP-CAN session signaling message include the IP-CAN type or RAT type of the new access network.
Step 506: the PCEF in the P-GW determines the UE performs the handover according to the information such as the user identity and PDN identity and so on, and finds the corresponding context before the UE performing the handover (i.e. the information such as the PCC rules and event triggers and so on), then sends an IP-CAN session modification indication message to the hPCRF through the Gx session1, and the IP-CAN session modification indication message includes the access information after the UE performing the handover, including the IP-CAN type or RAT type of the new access network.
Step 507: the hPCRF determines that the New BBERF is a Primary BBERF and the Old BBERF is a Non-Primary BBERF according to the association relationship among the Gx session1, S9 session and Subsession1, and also according to the access information reported by the Gx session1 and the access information respectively reported by the Gxx session1 and Gxx session 2.
Since the IP-CAN type or RAT type of the new access network reported by the PCEF in step 506 is the same as the IP-CAN type or RAT type of the access network reported by the New BBERF in step 502 at the moment, the hPCRF determines the New BBERF is a Primary BBERF and the Old BBERF is a Non-Primary BBERF. The hPCRF re-makes the PCC rules, QoS rules and event triggers according to the access information reported by the New BBERF, user subscription data and network policies and so on, and returns the IP-CAN session modification indication acknowledgement message to the PCEF, wherein the IP-CAN session modification indication acknowledgement message includes the updated PCC rules and event triggers.
Step 508: the P-GW returns the IP-CAN session signaling message to the gateway in which the New BBERF is located. In the implementation, the IP-CAN session signaling message is a proxy binding update acknowledgement message.
Step 509: the gateway in which the New BBERF is located returns a modification IP-CAN session reply message.
Step 510: the hPCRF sends the S9 session and QoS rule provision message to the vPCRF, and includes the PCC rules and event triggers updated in step 507 and the address of the New BBERF into the Subsession1 and includes Subsession1 into the S9 session and QoS rule provision message to send to the vPCRF.
Step 511: the vPCRF includes the QoS rules and event triggers in the Subsession 1 into the gateway control and QoS rule provision message to send to the New BBERF through the Gxx session2 according to the address of the New BBERF.
Step 512: the New BBERF installs and enforces the QoS rules and event triggers, and returns the gateway control and QoS rule provision acknowledgement message to the vPCRF.
Step 513: the vPCRF returns the S9 session and QoS rule provision acknowledgement message to the hPCRF.
The hPCRF also sends the updated QoS rules and event triggers to the Old BBERF, and includes the QoS rules, event triggers and the address of the Old BBERF into the Subsession1. The vPCRF decides to send the QoS rules and event triggers to the Old BBERF through the Gxx session1 according to the address of the Old BBERF.
In the process of the occurrence of the BBERF relocation, the hPCRF controls two BBERFs (more than two BBERFs may exist in certain scenarios) at the same time, and performs policy control according to the category of the BBERF (e.g. Primary and Non-Primary). When the BBERF relocation is finished, the Old BBERF needs to inform the hPCRF that its Gxx session in the visited network terminates so that the hPCRF will delete the QoS rules and event triggers and so on which are saved by itself for the Old BBERF (the Old BBERF is a Non-Primary BBERF at the moment). Or, after step 504 of FIG. 5, the New BBERF doesn't send IP-CAN session signaling to the P-GW, but determines to terminate its Gxx session in the visited network, and the vPCRF should also inform the hPCRF to delete the QoS rules and event triggers, etc. which are saved by the hPCRF for the New BBERF (the New BBERF is a Non-Primary BBERF at the moment) similarly. (Especially for inter-system pre-registration of the UE, the flow just needs to be implemented to the step 504.) In the related art, there is not effective methods to solve the problem that when the Non-Primary BBERF in the visited network terminates the gateway control session between itself and the visited PCRF under a roaming scenario, the invalid session information in the home PCRF can not be cleared in time, which leads to a redundancy and waste of the home network resources.
For a roaming scenario of the local breakout, those skilled in the art can easily find out that the above problem also exists in the case that the hPCRF needs to control the BBERF in the visited network.
Similar problems also exist in a multiple access scenario, and the multiple accesses are a technique that the EPC supports the UE to access one PDN simultaneously through the same one P-GW through multiple access networks.
FIG. 6 is a schematic diagram of the multiple access scenario, and as shown in FIG. 6, the UE is in the coverage of the non 3GPP IP access network and the 3GPP access network (i.e. the EPS network) at the same time, and the non 3GPP IP access network and 3GPP access network access the PDN through the same one P-GW. In this scenario, the UE attach to the EPS through multiple access networks, the P-GW allocates an IP address for the UE, and a PDN connection exists between the UE and the PDN. As different services adapt to adopt different network transmissions, the multiple access technique can choose an applicable access networks to transmit services according to the features of the services, and the multiple access networks can share the network loads so as to avoid network congestion. If the non 3GPP access network is WiFi, the service data streams of the Http and Ftp can be sent to the UE through the WiFi access network and the service data streams of the VoIP can be sent to the UE through the 3GPP. In this scenario, the PCRF also needs to control two (or more than two) BBERFs at the same time. (The BBERF is not classified into the Primary BBERF and Non-Primary BBER in this scenario.) When the UE decides to disconnect from an access network, the BBERF in the access network needs to inform the hPCRF, and the BBERF will terminate the Gxx session in the visited network, thereby informing the hPCRF to delete the related information of the BBERF. However, in the current multiple access scenarios, schemes related to these processing processes have not been involved either.